Scene 96/Scene 96 International Edition (Zyklop Software) (Disc 1) (1997).iso/diskmags/english/demonews/demonews.137

Text File | 1996-12-23 | 49KB | 1,005 lines

  ______/\__________________________       __  ________________ ___  /\_______
  \____   \  ________ _   _ ______  \     /  \|  \  ________   |   \/  ______/
  /   |    \  _)   \   \_/   \   |   \   /    \   \  _)   \    |    \______  \
 /    |     \       \   |     \  |    \ /          \       \  / \    \    /   \
 \_____     /_______/___|     /_______/ \____\_____/_______/_________/________/
     \_____/            |____/
                                                           Subscribers  : 2618
 DemoNews 137 - 21 December 1996                           Archive Size : 3683M

>------------------------------------------------------------------ Contents --

         Introduction
         Calendar
         Top Downloads
         New Uploads
         Articles
           Software Design for Demos ..................... Kiwidog
           Ratings - What Does It All Mean? .............. Phoenix
           NAID - Memories ............................... White Noise
           Java and Demos ................................ 3NO
           Hornet Archive And Jukebox Truth .............. David Greenman
           A Demo Scene Survey ........................... Nick
           The #trax Page ................................ b0b
         General Information

>-------------------------------------------------------------- Introduction --

 Ho ho ho, and welcome to DemoNews 137.

 _____Introduction

 [Note: I will be on vacation from 21-29 of December.]

 1997 is about 10 days away.  It's time to buy a new calendar and give the old
 one to the packrat in the family.  Everyone seems focused on Christmas and
 the passage of another year.  And why not?  A "year" is a really nice chunk
 of time.  It's long enough to define an era of the demo scene, yet short
 enough not to obscure memories of previous years.

 So what does 1997 mean to me?

   mkdir /demos/1997
   mkdir /music/songs/1997
   mkdir /graphics/images/1997
   ...

 :D

 I've been contributing to the scene since 1992.  There are others out there
 who have been around longer but their number is small and becoming more so.
 However, as a result of the roles I've had in the scene I feel I have a
 unique perspective on things.  I'd like to share some history and future
 predictions.

 _____The Past

 Since I wasn't in the PC scene until 1992 I can't really talk about things
 before then.  I do know that in 1992 things were drastically different then
 they are now.  A soundcard was a totally cool _optional_ component of your
 system.  Demos almost always outshined games in terms of technology and
 innovation.  There was no web.  The Internet was still a buzzword to most of
 the scene.  In September, Dan Wright started the Hornet Archive and DemoNews.

 1993 brought the scene a GUS and a new standard.  People started jumping on
 the 'net and sending international email without even logging onto a BBS! And
 with that change a lot of localization in the scene fell to the wayside...
 national scenes turned into continental ones.  Connectivity brought us faster
 access to new releases around the world.  Second Reality came out and a new
 generation of demo enthusiasts were born.  I personally consider 1993 to be
 the best year in modern PC demos history.

 1994 was like 1993++.  More people hopped online.  PC hardware was finally
 getting consistent.  You could on people in the scene having a 486 and a SB
 and/or GUS.  The music scene was starting to take off and become almost
 another entity.  Everyone still knew how to navigate in DOS.  Trying to run
 demos under Windows 3.1 was laughable.  People usually belonged to one group.
 IRC was a very nice size and mostly cool people hung out there.

 Then came 1995.  You could count on almost everyone having an email address
 and net connectivity.  Demo parties started popping up everywhere.  There was
 explosive growth everywhere.  Unfortunately, demos were starting to lose
 their technological edge and public appeal.  The masses who would have
 dropped their jaw at Second Reality in 1993 were bored to tears with Dope.
 The scene started to see the death of DOS in sight and were confused.  What
 OS to go to next?  Windows 95, Linux, or something new?

 Earlier this year I think the scene pretty much decided to stick with Windows
 95, for better or worse.  No longer could you count on people understanding
 DOS or being as resourceful as they were in 1993-1994.  A huge influx of
 newbies appeared in the music scene.  The BBS's have all but died and
 everyone and their kid sister creates web pages.  I used to give
 presentations at local computer clubs and high schools about the demo scene.
 The audience used to be captivated that such things existed.  Those same
 people today are more interested in Bevis and Butthead AVIs, obscene WAV
 files, and Java applets that crash '95 than they are about demos.  This is
 sad.

 _____The Future

 Today the scene is thinking about moving from DOS to Java (how odd that
 sounds).  I see this move as having one of two different outcomes.  First, we
 can rekindle some of the innovation and creativity we used to have and
 totally stun the world with our productions.  Or second, we get lumped into a
 general category: pretty cool Java applet makers.  I hope for the first but
 expect the second.  :(

 All is not lost though.

 One really neat thing the scene has is the ability to earmark its members.
 Even though the public has found our secret little world and invaded it, we
 still know who is _really_ in the scene and who isn't.  And it isn't a fuzzy
 distinction.  You either are in the scene or you aren't.  We know no middle
 ground.  I'm happy that this aspect of the scene hasn't changed.  It gives us
 a nice, solid, protective buffer from the outside world.

 Predictions?  I'm really hesitant to make any strong ones.  I do know that
 the scene is volatile and changing dramatically.  This is not a statement I
 would have made at the end of any other year except for 1996.  1997 will
 affect the very core of the scene... what OS we support, how we deal with the
 public (or avoid them), the death of the GUS standard, the commercial
 invasion, newbies who are totally lacking in basic skills, etc.

 _____Conclusion

 Of one thing I am certain.  1997 will define a new era of the demo scene.

 Snowman / Hornet - [e-mail]

>------------------------------------------------------------------ Calendar --

 Date         Event               Location  Contact Points
 ------------ ------------------- --------- ----------------------------------
 CANCELED!    Demobit             Slovakia  [e-mail]
                                            internet.sk/demobit/english.htm
 CANCELED!    Tesko               UK        [e-mail]
 09 Dec 1996  Movement            Israel    [e-mail]

                                       * <-- YOU ARE HERE

 27 Dec 1996  The Party 6         Denmark   [e-mail]
                                            www.theparty.dk
 15 Feb 1997  General Probe 3     Poland    [e-mail]
 28 Mar 1997  Mekka & Symposium   Germany   [e-mail]
 04 Apr 1997  X Takeover          Holland   [e-mail]
 12 May 1997  The Place To Be 4   France    www.mygale.org/05/dadu
 22 Aug 1997  AntIQ               Hungary   [e-mail]
                                            www.jpte.hu/~aboy

>------------------------------------------------------------- Top Downloads --

 This represents combined ftp/http transfers for the last 7 days.

 Sorry, my "get description" subroutine broke and I didn't have time to fix it
 before these statistics were generated.

 Total files downloaded   :     182,943
 Size of files downloaded :  27,130,504k

 Times File                             Description
 ----- -------------------------------- --------------------------------------

 -- /demos ------------------------------------------------------------------>

  198  /demos/1995/a/animate.zip
  155  /demos/1995/n/nooon_st.zip
  135  /demos/1993/u/unreal11.zip
  126  /demos/1993/s/symbolog.zip
  119  /demos/1996/a/ai_strok.zip
  118  /demos/1993/0-9/2ndreal1.lzh
  114  /demos/1996/p/paper.zip
  113  /demos/1996/m/machines.arj
  109  /demos/1993/0-9/2ndreal2.lzh
  108  /demos/1996/m/machines.a01

 -- /music ------------------------------------------------------------------>

  100  /music/songs/1995/s3m/a/aryx.zip
   76  /music/songs/1996/s3m/a/athought.zip
   66  /music/songs/1996/s3m/i/im_chron.zip
   60  /music/songs/1996/s3m/i/im_empir.zip
   59  /music/songs/1996/xm/r/raf-bost.zip
   56  /music/songs/1996/s3m/f/fm-mech8.zip
   56  /music/songs/1995/s3m/c/ctgoblin.zip
   55  /music/songs/1996/s3m/f/fa-bung.zip
   51  /music/songs/1996/s3m/c/ccs-eps.zip
   50  /music/songs/1996/xm/a/anthem.zip

 -- /graphics --------------------------------------------------------------->

   18  /graphics/images/1996/c/chantal.zip
   17  /graphics/images/1994/i/incest5.zip
   16  /graphics/images/1996/a/airwar.zip
   13  /graphics/images/1996/a/abc_land.zip
   12  /graphics/images/1996/i/impcybor.zip
   12  /graphics/images/1996/a/abc_pien.zip
   12  /graphics/images/1996/0-9/3dots.zip
   12  /graphics/disks/1996/pls_wild.zip
   11  /graphics/images/1996/v/voyeur.zip
   11  /graphics/images/1996/s/scarlet.zip

 -- /code ------------------------------------------------------------------->

   81  /code/effects/3d/3dtext.arj
   75  /code/effects/3d/fh-3dt18.zip
   74  /code/tutor/tut21.zip
   73  /code/effects/tunnel/araidsrc.zip
   68  /code/effects/rotozoom/pasroto.zip
   67  /code/effects/blobs/blobs.zip
   66  /code/effects/vector/rn_vect.zip
   66  /code/effects/phong/mphong.zip
   65  /code/effects/voxel/voxeltut.zip
   64  /code/effects/wormhole/stargate.zip

 -- /incoming --------------------------------------------------------------->

   64  /incoming/music/disks/fm-plast.zip
   62  /incoming/music/songs/xm/t2.zip
   55  /incoming/mags/sub00004.zip
   53  /incoming/demos/astralf.zip
   52  /incoming/code/chaossrc.zip
   50  /incoming/demos/riplview.zip
   49  /incoming/music/disks/u-lucid3.zip
   48  /incoming/code/dos32vbe.zip
   47  /incoming/demos/1k_intro.zip

>--------------------------------------------------------------- New Uploads --

 All ratings are subjective.

 Filename                        Size Rated Description
 ------------------------------- ---- ----- ----------------------------------

 -- /demos ------------------------------------------------------------------>

 /1996/0-9/1stepfix.zip             7 **    CAC96B:in4k:??: The First Step by
                                            | Brave Lamers
 /1996/a/abc_voda.zip             808 ***   Voodka by Absence
 /1996/a/ai_mutha.zip             936 ***+  CAC96B:demo:01: Mutha by Astroidea
 /1996/a/amitro.zip                 4 +     Amitro by Damage PC
 /1996/a/ashes.zip                 65 **    Ashes by Tate
 /1996/b/booth.zip                274 **    SEN96:demo:??: Booth by MFX
 /1996/b/br-1st.zip               841 [n/a] CAC96B:demo:??: First by Black
                                            | Rainbow
 /1996/c/clx_nog.zip             2802 ***   SEN96:demo:??: No Garden by
                                            | Complex
 /1996/c/cob.zip                   67 ****  SAT96B:in64:12: Cob by Nooon,
                                            | Orange
 /1996/c/comahomo.zip             567 **+   SEN96:demo:03: Homo by COMA
 /1996/d/dem3sat4.zip             404 *+    SAT96B:demo:06: Tartofraise by
                                            | Horizone
 /1996/d/dny-inac.zip              70 ***   CAC96B:in64:??: In Activity by
                                            | Dinasty
 /1996/e/elite.zip                274 *     The Elite Demo by Intra
 /1996/e/explora.zip             1509 ***+  SAT96B:demo:02: Explora by Bomb,
                                            | Oxygene
 /1996/f/fade.zip                  59 ***   CAC96B:in64:??: Fade by Exact
 /1996/f/fastark.zip             1283 ***   SAT96B:demo:03: Fast by Arkham
 /1996/f/fg-porno.zip             463 +     CAC96B:demo:??: Porno by Firg
 /1996/f/fizzygay.zip              61 **+   SEN96:in64:??: Peter and I Like
                                            | Fizzy Water... by TPOLM
 /1996/f/frs_clue.zip              78 **+   CAC96B:in64:??: Clue by Fresh
 /1996/g/grd_eqtn.zip              58 **+   Equation by The Grid
 /1996/h/h_empty.zip               66 ***+  SEN96:in64:01: Empty by Halcyon
 /1996/i/io3_4k.zip                15       Intel Outside 3 4k Intro Compo
                                            | Entries
 /1996/k/kala.zip                1419 [n/a] SEN96:demo:??: Kalanviljelylaitos
                                            | by Tempest
 /1996/m/mantmag.zip             2084 ***+  SAT96B:demo:01: Magma by Mentasm
 /1996/m/muna.zip                1053 *     SEN96:demo:01: Muna by Hirmu
 /1996/n/ntl.zip                   81 **    SAT96B:in64:06: Not Too Late by
                                            | Skytech Group
 /1996/p/p-statio.zip              71 ***   SEN96:in64:??: Station A. Hoffman
                                            | by Paragon
 /1996/p/pastel.zip                19 **+   CAC96B:in4k:??: Pastel by
                                            | Controlled Dreams
 /1996/p/pearl.zip                 60 ***   Pearl by Poison
 /1996/p/pierre2.zip              910 [n/a] SEN96:demo:??: Pierre Deux by Coon
 /1996/p/probe.zip                602 ***   CAC96B:demo:03: Probe by
                                            | Euthanasia
 /1996/r/ravetro.zip               69 **+   CAC96B:in64:??: Ravetro by Byteam
 /1996/s/sat_ast.zip              223 *+    SAT96B:demo:05: Narguileh by AST
                                            | System
 /1996/s/sck-onyx.zip            1546 ***+  CAC96B:demo:02: Onyx by Shock
 /1996/s/sphere.zip                76 ***+  CAC96B:in64:01: Sphere by Mortal
                                            | Compact
 /1996/s/ste-08.zip               123 *+    N0ll 8tta by Syntax Terror
 /1996/s/ste-die.zip              111 *     Doo by Syntax Terror
 /1996/s/ste-stlf.zip             423 **    REM96:demo:04: Don't Get Stajlish
                                            | (final) by Syntax Terror
 /1996/s/super_.zip               691 **+   SEN96:demo:02: Superman's Day Out
                                            | by TPOLM
 /1996/t/talo.zip                 116 *     SEN96:demo:??: Talo by P33107
 /1996/t/the_cube.zip              19 ***   CAC96B:in4k:01: The Cube by Fishy
 /1996/t/tls_time.zip             580 ***   Time by The Lost Souls
 /1996/u/uf_depr.zip             1295 **    CAC96B:demo:??: Depravity by
                                            | United Force

 -- /party ------------------------------------------------------------------>

 /invites/1996/cache96a.zip       532 [n/a] CAC96B::: Cache '96 Autumn
                                            | Invitation Intro by Unicorn
 /invites/1996/demol2.zip         216 ***   DML96B::: Demolition II '96
                                            | Invitation Intro by Ws, Solen
 /reports/1996/p2b4_myo.zip      3516 **    The Place To Be IV Slideshow by
                                            | Myopath Crew
 /results/1996/cac96a.res           0       CAC96B::: Cache '96 Autumn Results
 /results/1996/cov96res.txt         3       COV96::: Coven '96 Results
 /results/1996/w96res.zip           4       WIR96::: Wired '96 Results

>------------------------------------------------------------------ Articles --

 ---------------------------------------------------------------------------->

 :: "Software Design for Demos"
 :: Kiwidog - [e-mail]

 _____Introduction

 Hello everyone. :)

 As I wrap up the Intro to 3D series in extremely late fashion in my spare
 time, I've decided to start writing another article series on a topic not
 talked about very often in demo coding... software design.  This has been a
 somewhat touchy subject because good coding design practices are hard to
 learn in an environment where ultra-rapid speed is all that counts, and where
 the coders typically are self-taught individuals in their late teens to early
 twenties.

 From what I've seen, there are three prevalent views among demo coders I've
 talked to; they either A) think good coding practices necessitate intolerably
 slow code, B) think good coding practices require unnecessary effort when
 writing demo code, and/or C) think taking the time to learn good coding
 practices wouldn't have much benefit as far as demos go.

 While B may be true depending on your situation, A and C are most definitely
 myths, and I think these myths are slowly contributing to the scene's gradual
 "falling behind" as far as innovations go.  The times of making tiny single
 routines that look super-impressive to everyone are over, and making large
 demos that have impact is getting more and more difficult with time. As a
 result, people are either making crappy or unoriginal demos (such as the
 3D-engine-object-show rut), or even worse, not making demos at all... and the
 scene is losing its edge because of it.

 For the past 5 months or so, I've been employed at Raven Software, a game
 company whose games you've worst case seen on the shelves, best case played
 and enjoyed (I'm not going to plug the company since this is not a sponsored
 article, but you knew I'd bring them up somewhere :)  In these 5 months I've
 ended up learning more than I could possibly fathom previously about writing
 good code.  Not just fast code or small code.... _good_ code.  If you don't
 know what that means, you haven't had to deal with the frustration of coding
 a large project, and if you think you know what it means and think it's not
 as "good" really because it means bloated and slow, you're wrong.

 I think that if demo coders took the time to learn some good coding practices
 and software design, it would not only allow them to focus more on the demos
 themselves, but would also give them more power to really do in demos what
 they enjoy doing the most... creating.  If you're spending forever trying to
 get your code to work with your teammates' code, or if you find yourself
 rewriting your VGA unit every month, that's time taken away from the fun
 part, the creating.

 In addition, for those of you that are thinking of bringing your programming
 skills into the outside world, good software design skills are a huge plus
 (I'm not saying this as a prospective employer, as I'm not... I'm saying this
 as a fellow coder who wishes he could have learned 2 years ago what he's
 learned in the past few months, as it would have been incredibly helpful).

 If the scene's going to get out of its rut and continue to move on to
 bigger-better-faster things, it's also got to add one more property to the
 list... smarter.  Without coding smarter, coding faster won't do you any good
 once the project gets intense.

 So that's what this series is about.  In this article series I'm going to
 show you how to start creating a comprehensive demo library and development
 system, which I am working on myself only shortly before these articles are
 being written.  We'll build this development system from the ground up, and
 in the end you'll be able to take the practices used and move them over into
 your own code, whatever your language or compiler may be.

 This is not a rigid "cut and paste my code and you will code perfect demos"
 thing by any means; at the time of this writing I'm still working on making a
 full demo, so I can't speak for this stuff being gospel (actually it can most
 certainly be improved).  But I think it's the _principles_ that are
 important, and those don't change regardless of what language you prefer or
 how fast your texture mapping algo is.  Think of it as a "helpful hints" type
 of thing. :)

 The key points I'll be going over during this whole shindig:

      - Good naming conventions
      - Organization for large projects
      - Code Re-Use

 along with a couple demo-specific things that I've found useful, such as
 process queues (fake multitasking for effects) and internal consoles for
 on-line development.

 This is not a basic intro series like I did last time; this is a bit more
 high up.  Not _too_ high up, but a bit more than before.  To really gain from
 these articles you'll probably have had to have had frustrations in the past
 with large project organization (I could name a certain person from Psychic
 Monks that would fit this category from this past NAID, but he already knows
 who he is :)  Trust me, I've had just as much frustration, so you're not
 alone.

 _____Dammit Kiwi!

 Here's the part where I'm sure there will be a lot of coders screaming
 "DAMMIT KIWI!", and before you do, read the whole section.

 The language of choice for me to write the code for this series is C++.

 If you find yourself screaming "Demos using C++?  What the hell is he
 thinking?  C++ is bloated and slow, it's what you write Windows programs
 with, not demos!  This sucks!", then perhaps reality will set in when you see
 that C++ code overhead is.... well....

 Zilch.

 That's right, nothing.  No overhead.  The only reason C++ code can be slower
 than C code is if you abuse it, and granted it is easy to abuse... but you
 don't have to (BTW when I say C++ code I mean using the object-oriented
 extensions of C++... in other ways C++ is really just a superset of C).

 Want proof?  In later articles you'll have proof yourself with the example
 source (which for the people who read my 3D articles, you'll be happy to know
 that this time the example source is already written).  But for now, let me
 give you an example.

 I have a program called PROCTEST.CPP which is the main file of a project.
 Inside this program there is one "routine" declared which is a function set
 framework used for a repeated operation; this routine happens to be a set of
 empty functions, so they do nothing.  An instance of this routine is created
 by declaring a "process", which is a class that takes a routine frame to tell
 it what it's supposed to do, and this process is set to "spawn" on the
 execution of a particular "event", a linked-list structure holding sets of
 manual spawn and kill orders.

 Events can be rigged to certain things like music sync points or other
 process kills, but in this case, the event is executed directly.  The spawned
 process is now added to the process execution queue, and this queue is
 executed every frame by checking all processes in the queue, getting current
 timing information for each, (built-in profiling), and executing the process'
 prime functions, checking for any hooked events or internal self-kills from
 the process.

 Another process is created from another routine frame, but this routine does
 something; it quits the program if a key is pressed.  This process is also
 set to spawn at the initial event, so during the main process queue cycle,
 both an empty process and a key-quit process are being run, as well as all
 the other empty slots in the queue being checked for validity information.

 Sound confusing?  That's okay.  Sound huge?  Understandable.  Sound object
 oriented?  Extremely.  Wanna know how long it takes to execute a frame,
 built-in-profiling-multi-process-execution and all?

 On my P75 at work, 0.000244 seconds, under Win95 even.  This is an accurate
 timing, as I'm reading the PIT directly (< 900ns granularity) which is not
 affected by Win95's timing quirks except to point out that normal interrupt
 latency exists (i.e. without interrupts the result would be even better than
 it already is!).

 So if you want to complain about overhead, you're complaining about the wrong
 thing.  We're talking about a small fraction of a screen clear's worth of
 clock cycles, for something that on the outside might appear "bloated and
 slow".  If you want to spend your time complaining about clock cycle loss,
 optimize your polygon routines more... but don't go whining that C++ is
 inherently slow; you'd be barking up the wrong tree and only doing yourself a
 disservice.  How you _use_ the language is what counts.

 There, now that that's said...

 _____So What Exactly Are We Planning To Do?

 I'm planning to cover this development process piece by piece, first with how
 to arrange for large projects, followed by naming conventions, and then on to
 starting the library itself.  Once you get the hang of how the system works,
 the library's internals won't matter too much (we'll only be doing a few of
 them with this series); you'll be able to use your existing knowledge to fit
 the pieces together.  The internals we will be building here will be the ones
 you might not have dealt with, namely the process queues and internal console
 mentioned before... so if you take nothing of the software design process
 away with you, you'll at least take away two more techniques that one way or
 another could help you in your coding.

 I'll also be going over some of the nuances of using C++ for you C folks
 here as we go on; there's really not as much to learn as you might think.

 This series will undoubtedly spread over many articles, but unlike my 3D
 series there's no rigid "this article this topic" structure or timeline
 (which should make Snowman happy as far as size limits go :)  I don't plan
 on the series lasting forever, but there might be a few weeks between
 subsequent articles to compensate for the fact that I have a job to deal
 with too (still, there shouldn't be too much lag... the code's already done
 this time, and the article-writing time isn't nearly as long as the code-
 writing time, so we should be in good shape).

 BTW, all my code will be written for Watcom C++ 10.0+, so when you see code
 or makefile references, that's what I'm using.  Any specific stuff to the
 compiler though should be minimal, and besides as I said before, it's the
 principles that matter.

 Well, now that I've taken up half my article space for this opening volume,
 we might as well begin... :)

 _____Setting Up for Large Projects

 There are several principles that come in handy when you want to move from
 a small project arrangement to a large project one.

 1. Multiple Directories and/or Version Control

 If more than one person is working on the project, Version Control software
 is a good idea, whether you make it yourself or get some kind of actual VCS
 package like RCS or MS SourceSafe (BTW I highly recommend SourceSafe for you
 MSVC developers out there).  Version Control lets you "check out" files from
 a particular project, edit them, and check them back in when you're done...
 that way no two people are editing the files at the same time. It can get
 nasty if two people are updating a module and one person is making additions
 to an older version than another person has, and when the updates are
 completed the stuff from the older version remains while other newer version
 changes by other people are wiped out.  Version Control prevents this from
 happening.

 If you're a single person, Version Control might also be helpful to you, but
 if you don't have it, then you'll want something else to help structure where
 your files are located (as there is no package present to manage the
 locations for you like VCS will), such as multiple source directories.
 Breaking down your project into multiple subdirectories for individual
 components can help assist in making changes and updates, as you always know
 where your code for a given type of module should be.

 2. Make Use of Library Files

 The .LIB extension seems all too uncommon these days, but it can be very
 helpful.  For one, projects using a common .LIB will not link with any dead
 code from the library; only the functions used will be linked in (for you
 Pascal folks, this basically means use units extensively).  In addition,
 the .LIB can then be a project in itself, so any of the code meant for the
 library can be kept in the library project _only_ and nowhere else, allowing
 you to keep track of where you should make changes.  Not to mention that
 if the the .LIB is a project, then when this project is updated and other
 projects are meant to use the .LIB, all that's required is a relink by the
 other projects, and everything is new and fresh.

 3. Use IDE Projects and/or Makefiles

 If you have an IDE associated with your compiler that supports projects, take
 advantage of it.  If you don't (or you just don't want to use it, like in the
 case of Watcom's Windows IDE which I despise), and makefiles are supported,
 use them.  Even better, in the case of projects that use common resources
 (like a common .LIB as mentioned above), you can set up a single makefile
 with variables that can be changed on the command line for individual
 projects.  As an example, my arrangement has a subdirectory \PROJECTS, with a
 single makefile PROJECTS.MAK.  Each project I make goes underneath this
 directory, and they all build with ..\PROJECTS.MAK, so there's only one
 makefile to change if changes are required.

 4. Use Generators

 Generator programs, such as programs to generate a class frame with a
 particular name or "buildme" batch file for a particular project, only take a
 few minutes to write yet can save you an incredible amount of time and
 headache.  In the case of the above PROJECTS.MAK example, having a small
 program called NEWPROJ that creates a project directory and writes a batch
 file "BUILDME.BAT" in the dir with the line "wmake /f ..\projects.mak
 TARGET=(command line param)" is quick and simple to write, but saves a nice
 chunk of time in the long run.

 For module frames, doing a similar program that writes an entire module
 template with a specific name saves tons of grunt work cut&paste time, and by
 the same token gives you a common frame to work with so your code is
 consistent. I wrote my class frame generator in 15 minutes, but I'm positive
 it's saved me at least 5 hours of grunt work time by now. :)

 5. Have Effective Naming Conventions

 This last one is a topic unto itself, which I'll get to next time.  Having
 some kind of standard way to name your variables, functions, and structures
 may seem too "nitpicky" or "anal" at first, but it can save you phenomenal
 headache over time, ESPECIALLY if there's more than one person involved in
 the project.  I'll get into specifics in the next volume.

 _____Conclusion

 Welp, my space has run out, so I'm taking off.  Next time we'll discuss all
 the ins and outs of good coding style and naming conventions, and why no
 matter what convention you choose, you should choose one.

 Until then, :)

 Chris Hargrove
 a.k.a. Kiwidog/Terraformer,Hornet alumni
 Technology Programmer, Raven Software

 Disclaimer: These articles are in no way affiliated with Raven Software, and
 represent the views and opinions of the author solely.

 ---------------------------------------------------------------------------->

 :: "Ratings - What Does It All Mean?"
 :: Phoenix / Hornet - [e-mail]

 _____Introduction

 Ratings - What Does It All Mean?

 Ever since last year, we at the Hornet Archive have been stamping a little
 rating onto each demo, song, musicdisk, artwork, and sometimes even coding
 util that gets uploaded.  These ratings have certainly helped people in
 deciding which releases are the "best" and which to not waste their time
 downloading, but at the same time they've been a source of controversy and
 confusion.

 Assuming you've cared at all, you've probably asked yourself "what do all
 these stars and other weird ratings mean?" Well, here's your humble demo
 reviewer to attempt an answer to that, with my personal scale for demos.

 _____The Scale

      + - Total crapola. Offensive. A bad joke. Why did you make me watch
          this?

      * - Ugly. Lame. An average joke.

     *+ - A really poorly done serious demo.  Effects from 1991, bad gabber,
          no design.  Or, a pretty good joke demo. :)

     ** - Still below par.  Old/overdone effects, unfitting music, little to
          no gfx.

    **+ - Mediocre.  May have some modern effects, but poorly used.  Music
          could use some improvement.

    *** - Decent/slightly above par.  The minimum of what I'd expect from
          current demos.  The music is listenable and fits with the demo. Has
          modern effects, but some may be overdone.  Some OK gfx.

   ***+ - Very good.  May have a new effect or two.  There's some design with
          graphics and transitions.  "Catchy" music.  I start keeping demos on
          my hard drive at this level.

   **** - Excellent.  These are usually the smaller party winners.  A
          memorable design/theme with good gfx (if any).  Many interesting
          effects, and high quality, well-synchronized music.  I start
          recommending demos to others at this level.

  ****+ - Outstanding.  I'd only give about 5 or so demos this rating per
          year.  Usually the major party winners, they contain almost all new
          effects, including one or two ingenious ideas.  Well-fitting music
          once again, and usually top-notch graphics, if not design.

  ***** - Godlike.  I'm saving this for the mother of all demos.  After
          watching several hundred of them, deep inside I still believe that
          there will be some that make me fall off my chair.

  [rip] - Uh oh.  Contains mostly code/gfx/music that obviously came from
          another release, but wasn't credited.  I've given a couple of these,
          and deleted one intro that was a complete rip. Boo.

  [n/a] - Most of the time, this means I could not get the demo to work. My
          current system is: 486-DX4/75, 8MB RAM, 1MB ET4000 VLB VGA, GUS ACE
          512k, and SB Pro.  Not too great for recent demos (although I think
          it should be), but hopefully it will soon be: 6x86/120, 16MB RAM,
          2MB S3D PCI VGA.  Under various software configurations I can run
          about 90% of the demos, but my goal is 99% under the new system.

  (blank) In my departments, party results and pictures do not get rated;
          graphics programs and newsletters do not either.

 _____Factors In Demo Ratings

 Some of those demo ratings may seem a little more unusual than others, but I
 have a logical explanation for each one.  These are some of the factors that
 go into the ratings.

  Music + catchy, well-synchronized, style fits mood of demo
        - boom chi boom chi rez boom rez chi

  Code  + new effects, creative combination/use of old effects
        - old effects, and even worse, overused effects (e.g. 2D embossing/
          bump, tunnels, polar plasma, polar ANYTHING, lens flare, circling
          bobs [they may have looked pretty in Caero but they're just bobs :)]
          strobing vectors, etc.)

  Design + creativity gets points (e.g. Toasted, Paper).  So do transitions,
           well drawn logos and pictures, and good use of color.
         - trying to imitate stuff done before, or just not having any design
         I'm neutral on "thematic" demos (like Craw Prod. stuff).  Sometimes
         they work, sometimes they don't.

 _____The Hitlist

 If it was not made clear in DN #135, here's who rates what:

 /demos, /party - Phoenix (me :)

 /graphics, /mags - GD

 /music - a small group of people, who should probably remain anonymous since
          this directory gets the most threats from ratings. :) JTown is the
          file mover, however.

 /code - Gee, I don't think any of us know who rates this. :)  Sometimes it's
         Snowman, sometimes Trixter, it's even been Daredevil before.

 _____Conclusion

 Anyway, I hope I helped clear up some confusion in demo ratings.  All that is
 left is confusion in other ratings.. well, I'll leave that to them. :)

 ---------------------------------------------------------------------------->

 :: "NAID - Memories"
 :: White Noise - [e-mail]

 You were at NAID, in 95 or 96?  You entered something in a competition there?
 A song, a graphic, a demo, an intro?  Then you can help the Ultimate NAID
 collection.  Have a look at naid.conceptech.qc.ca, the NAID - Memories and
 help us out by sending in what you submitted.

 Also, should you have pictures of the party in digital format, or artifacts
 such as ticket stubs or anything that you think could be nifty to add to this
 Monument to NAID, please send it over.

 The ftp site is at ftp.naid.conceptech.qc.ca/incoming/naid

 Thanks for your help.  Long live the memories...

 White Noise.

 (used to be in Hornet now lost somewhere in a void between his keyboard and
 his schoolbooks)

 ---------------------------------------------------------------------------->

 :: "Java and Demos"
 :: 3NO (formerly Vector) / Vinlandia, Tpolm Kanada - [e-mail]

 Hello again.  Last week, I outlined my desire to explore Java as a possible
 demo platform.  Since the publication in DemoNews last week I have received a
 number of responses, all positive.  I have decided that instead of doing a
 newsletter, I will write a regular column in DemoNews on the subject, most
 likely every 2 weeks or so.

 Just some brief notes for this week.  I noticed on cspid (C-sped? :) about a
 week ago mention of a web site with some demo-effects on it.  Everybody
 interested should check this out - it has a number of fire effects, as well
 as a little starfield, which run directly in the web browser.  You can find
 this at http://www.uni-koblenz.de/~cohnen.  It's a good example of what can
 be achieved even at this early stage.

 Also, one of the best sources of general Java information is the Sun Javasoft
 site, http://www.javasoft.com.  This contains various tutorials and docs,
 including a complete outline of the High-level Java language and the Java
 virtual-machine (JVM) specification.

 This brings up an important point - I would like to start keeping track of
 sources of demo-oriented Java sites, and will hopefully put up an index site
 at some point.  If anyone knows of any good sites, please email me.

 The next thing I would like to talk about is Java music-playing.  I was
 talking to Mikmak on irc the other day, and he seemed quite interested in the
 possibilities of Java, despite some of the shortcomings.  (NO unsigned types
 - argh!).  He is apparently working towards a Java version of mikmod, and
 told me that Rao has been playing with as well.  In any event, if music can
 indeed be played properly in Java, we could be seeing a few basic demos being
 produced in the near future.

 A Java tracker could also be interesting - portability is assured, and would
 be a step towards more direct, on-line co-op composition.  Makes me think of
 that little blurb on the Kosmic web-page. :)

 The last thing I want to mention is the whole issue of Windows 95 and DirectX
 demos.  Part of the reason I want to start exploring Java as a demo platform
 is because of Windows 95 and DirectX.  I feel DOS is gradually losing it's
 relevance, and I also think it would be horrible if we all started making
 Win95 and DirectX demos.

 As one person on cspid said, it wouldn't be about finding new tricks but
 finding bugs in the OS, and from my own experiences with Windows programming
 I have to concur.  I think Java is a much more exciting platform for demos,
 because it is virtually uncharted territory.  Besides, there's no reason why
 Java in the future couldn't support all the accelerated hardware that DirectX
 is supposed to.

 Well, this is all I have for this week, and my next column will be 2 weeks
 from now, hopefully.  Have a good holiday, and make sure to email me if you
 have any feedback, info, or good ideas.

 ---------------------------------------------------------------------------->

 :: "Hornet Archive and Jukebox Truth"
 :: David Greenman

 _____Introduction

 When the Hornet Archive started running out of room, one of the suggestions
 people made over and over again was to have a CD jukebox on wcarchive for
 additional storage.  I tried explaining why this was a bad idea, but people
 wouldn't listen.  Here with us today is David Greenman, official maintainer
 of ftp.cdrom.com (wcarchive).

 _____The Scoop

 > David, could you write a 3-4 paragraph summary of why using online CDROMs
 > as additional storage for wcarchive is not feasible?  I've have been
 > getting asked this over and over again.  As much as I try to explain about
 > slow seek times, bad performance in multi-user environments, etc., your
 > words would carry much more weight.

 Here are a few of the reasons:

 1. [most important] The archives change too frequently (usually daily), and
    this makes permanent storage impractical.

 2. We don't have physical access to the machine without an hour's drive to
    San Francisco; see #1. We don't pay CRL for micro-management of the
    machine, and co-location is the only way we can afford to provide the
    level of service that we do.  Getting them to insert one or two CDROM's a
    month is perhaps possible, but one a day (or even one a week) is not.

 3. Single CDROM drives are expensive in the MB/drive area - much more
    expensive than hard drives.  While juke boxes bring this price down
    considerably, we can't use them because they are designed for single-
    reader access, not 500-reader access. I'm afraid that the little carousel
    would really be a spinnin'. :-) ...and people would see about 512 byte per
    10 seconds transfer rates.

 You could argue that some archives don't change (like releases of software,
 for instance), but even for those, we simply have no archives that are
 trafficked so infrequently that #3 wouldn't kill you every time. Archives that
 are so unpopular where #3 wouldn't be a problem would (should) be deleted
 since they don't contribute significantly to the value of the archive.

 Of course there is also the problem that, while specific software releases
 don't change, new ones do come out occasionally and the sum total of all new
 software releases that are put up on wcarchive each day would still make
 #1/#2 a show-stopper.

 David Greenman
 Core-team / Principal Architect, The FreeBSD Project

 ---------------------------------------------------------------------------->

 :: "A Demo Scene Survey"
 :: Nick - [e-mail]

 [Editor's note: You won't believe how much trouble I had in printing this
 text.  Nick emails me a survey (for a class project), I fill it out, send it
 back, and promise to put a copy in DemoNews.  Then I lost the survey. Then
 the deadline passed.  Finally, Nick decided that he'd would persue the
 project outside of school and could extend the deadline.  So here we go.]

 _____Introduction

 Note: I realize that time is limited, so if you don't feel like answering all
 the questions, don't; the first two and the demographics would be nice, or
 maybe just skip the first five, and head straight into the multiple choice.

 _____Essay Questions

 1.  What does the scene mean to you?

 2.  In your mind, what is the best quality of the scene?

 3.  What is your favorite demo?  Why?

 4.  What first interested you about the scene?  Or, how did you first learn
     about/get into/whatever the scene?

 5.  Do you see Microsoft as a necessary evil, or just evil? ;)

 _____Multiple Choice

 6. Do you think the scene will shed its underground? roots?

    A.  Yes.
    B.  No.
    C.  I hope not!

 7. Do you think the scene will ever be superseded by larger (perhaps
    corporate) interests?

    A.  Maybe.
    B.  No way!
    C.  Why are you asking this?

 8. By the year 2000, do you think the scene will have:

    A.  Grown immensely
    B.  Grown, but not by an extreme margin
    C.  Stayed roughly the same size
    D.  Started to die out
    E.  Become a force to reckon with

 9. By the year 2000, how do you see your relationship with the scene?

    A.  Still immersed in the wonderful world of demos.
    B.  Reduced role.
    C.  Casual Observer.
    D.  Moved on to other things.

 10. How do you plan to use your experience in the demo scene to support
     yourself later in life (or how *did* your experience..)

    A.  Go into business for myself.
    B.  Find a job in a related computer industry.
    C.  It has really just been a hobby.
    D.  I plan on using the experience to change the computing status quo.

 _____Demographic Information (optional)

     Age:
 Country:
   Group:

 _____Conclusion

 When you are done, please cut out this survey from DemoNews and mail it to
 [e-mail]. Thank you for your time.

 ---------------------------------------------------------------------------->

 :: "The #trax Page"
 :: b0b / Chill, Ultrabeat, Mazurka - [e-mail]

 There's this little page out here on the www called the #trax page.  It's the
 semi official home of all the people who frequent the IRC channel, #trax.  In
 recent times, people beyond the scope of the #trax culture have also logged
 onto the page and added their entries.  It has become more of a demoscene
 megalink page now.  The page gives people the ability to edit their own
 entries; most people log onto the page to modify their bio's on a regular
 basis so the page stays very up to date for the most part.  Or so that's the
 theory.  :)

 Currently the page has over 340 people listed, over 150 pictures of scene
 people, and about 20+ group listings (and growing).  One of the newest
 features of the page gives everyone the ability to add/edit and delete
 'releases' to their bio's.  Your releases can be hyperlinked to an FTP or
 HTTP server where the file might be stored.  This feature although VERY cool
 has not really caught on.  :(  So let's see you people adding in your
 releases!!!

 Recent updates include:

   - fixed links section (took out pictures, looks nicer now).
   - fixed some source code bugs that no one else really noticed.
   - added about 15 new pics and updated about 10 other pics.
   - added about 4 new groups.
   - shrunk the damn logo so that it doesn't take nearly as long to load now.
   - fixed all the pages so that you can resize them and they don't screw up.

 Some people may have noticed lately that there were a lack of updates.  The
 reason being that I got very busy at my "real job".  Luckily things have
 slowed down due to the X-mas season and I was able to reply to the 100+
 messages in my mailbox regarding the page.  If there anyone now who has sent
 me something via e-mail and has not received a reply please resend your
 message.

 Lastly, there are still over 100 people who have not logged onto the page to
 change their default password.  On 01 February 1997, I will be deleting all
 entries that have not updated your password.

 The default password is: XXXXXX

 Six x's.  So login and change it if you havn't.

 Thanx.

 And remember: http://www.spaz.com/trax

>------------------------------------------------------- General Information --

 _____The Hornet Archive

 Master Site : USA (California)   - (ftp|www).hornet.org/pub/demos
 Mirrors     : Portugal           - ftp.telepac.pt/pub/demos
               Sweden             - ftp.luth.se/pub/msdos/demos
               South Africa       - ftp.sun.ac.za/pub/msdos/demos
               USA (Wisconsin)    - ftp.uwp.edu/pub/demos
               USA (Pennsylvania) - ftp.co.iup.edu/code (from /demos/code)

 _____DemoNews

 New issues are posted to /incoming/info.
 Old issues are in /info/demonews.
 Supplemental files are in /info/dn_other.

 How to subscribe:

 Mail - [e-mail]
 Body - subscribe demuan-list FIRST_NAME LAST_NAME    _or_
 Body - subscribe demuan-list HANDLE

 DemoNews is sent to your e-mail's "Reply-To" field.

 _____Contact Address

 [e-mail]

>------------------------------------------------------------------------------

EODN